SCPで実現するAWS 組織ガードレール〜意図しないサービス利用を防ぐ〜

はじめに

AWSを複数アカウントで運用する際、「検証環境で誤ってサービスを有効化してしまった」という事故は決して珍しくありません。特に、長期コミットメントが必要なサブスクリプション型サービスは、一度有効化してしまうと取り消しが困難です。

本記事では、AWS OrganizationsのService Control Policy (以下SCP)を活用し、組織全体で「そもそも有効化できないようにする」予防的統制の実装方法を紹介します。

長期コミットや費用が高額なサービスの例

まず、検証環境で誤って有効化しないよう特に注意が必要なサービスを紹介します。以下のサービスは、一度有効化すると長期のコミットメント契約が発生し、想定外のコストが継続的に発生する可能性があります。検証環境での誤操作を防ぐため、SCPによる制限が有効です。

Shield Advanced

Shield Advancedは、DDoS攻撃等の外部の脅威からアプリケーションを保護するためのサービスです。Shield Standard（無料）と異なり、Shield Advancedはネットワーク層（L3/L4）だけでなく、アプリケーション層（L7）のDDoS攻撃にも対応し、Shield専門チームの24/365サポートも受けられます。

Bedrock プロビジョンドスループット

Bedrockのプロビジョンドスループットでは、特定のモデルに対して事前に固定料金で専有のスループット容量を確保できます。これにより生成AIモデルの安定した推論のスループットを確保することができます。

Nova Forge

Nova Forgeは、Amazon Novaを使用して自社独自のカスタムモデルを構築するためのサービスです。独自のデータをもとにトレーニングを行うことで、特定のユースケースに最適化されたモデルを構築できます。

上記はいずれも期間コミットメントのあるサービスとなっており、通常は本番環境などで承認を得て契約し、検証用途の環境ではサブスクリプション契約を行わないケースの方が多いかと思います。Shield AdvancedとNova Forgeは1年間のサブスクリプション契約（Nova Forgeは年間$100,000程度）、Bedrockプロビジョンドスループットは1～6か月のコミットメントが必要です。これらのサービスでは、請求アラート等で気づいてから止める（発見的統制）では手遅れなので、そもそもサブスクリプションを有効化するアクション自体を実行させないよう、事前に制御する必要があります。

実装例1: 特定アクションを禁止するSCP

Organizations配下の利用者向けOU（Organizational Unit）に以下のSCPを適用することで、特定サービスのアクションを直接ブロックします。

ポリシーの解説

このポリシーでは、ShieldやBedrockの特定のアクション（CreateSubscription、CreateProvisionedModelThroughput）をブロックしています。また、Ground StationやPrivate 5Gなど、検証環境では通常利用しないサービスについては、groundstation:*のようにサービス全体のアクションをブロックしています。

• shield:CreateSubscription : Shield Advancedのサブスクリプション契約
• bedrock:CreateProvisionedModelThroughput : Bedrockプロビジョンドスループットの作成
• groundstation:* : AWS Ground Station（人工衛星との通信サービス）の全アクション
• private-networks:* : AWS Private 5G（プライベート5Gネットワーク構築サービス）の全アクション
• braket:* : Amazon Braket（量子コンピューティングサービス）の全アクション
• outposts:* : AWS Outposts（オンプレミス環境にAWSインフラを設置するサービス）の全アクション

実装例2: IAMタグベースの制御

Nova Forgeのサブスクリプション契約は、特定のタグが付与されたIAMロールでのみ実行できる仕組みになっています。以下にあるように、操作するIAMロールにkey: forge-subscription、value: trueのタグを追加する必要があります。このタグがないとコンソール上で「サブスクリプションを申し込む」ボタンが非活性になります。

そこで、このタグ自体を付与できないようにするSCPを設定します。

動作確認方法

SCPを適用した後、IAMコンソールでロールにforge-subscriptionタグを付けようとすると、以下のようなエラーが表示されます。

エラーメッセージには「User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/xxxxx is not authorized to perform: iam:TagRole on resource: role Forgetest with an explicit deny in a service control policy」と表示され、SCPによって明示的に拒否されていることが確認できます。

参考: もしタグを付与できてしまった場合

参考までに、SCPで制限していない環境でforge-subscriptionタグを付けてしまうと、どうなるかを紹介します。

まず、IAMロールにforge-subscription = trueのタグを設定します。

すると、Nova Forgeのサブスクリプション画面で申し込みボタンが活性化されていることがわかります。

このように申し込みが可能になってしまいます。（検証時は誤ってクリックしないよう細心の注意を払いました）
検証環境ではこのような状態を防ぎたいため、SCPでの制御は重要になってきます。

SCPの動作検証: IAMポリシーシミュレーターの活用

タグベースの制御は、IAMコンソールでタグが付けられないことを確認すれば動作確認できます。
しかし、APIベースで禁止しているアクションについては、実際にサブスクリプションを有効化するわけにはいきません。

そこで活用するのが IAMポリシーシミュレーター です。

IAMポリシーシミュレーターを使うと、実在するアカウント内のユーザーやロールに適用されているポリシー（IAMポリシー、SCPなど）を組み合わせて、特定のアクションが許可されるかどうかを疑似的に検証できます。実際の環境で設定されているポリシーをそのまま評価できるため、SCPが正しく適用されているかどうかを検証することができます。

使い方

1. IAMコンソールから対象のロールを選択
2. 「許可」タブで「シミュレート」ボタンをクリック（または[IAMポリシーシミュレーター](https://policysim.aws.amazon.com/)に直接アクセス）
3. サービスで「Bedrock」を選択し、アクション「CreateProvisionedModelThroughput」を選択

4. Run Simulation（シミュレーションを実行）をクリック
5. 結果が「denied – Denied by AWS Organizations」となっていることを確認

同様に、Shield AdvancedやGround Stationなど、他の制限対象サービスについても検証できます。この方法であれば、SCPのガードレールが意図通りに機能していることを、実際にリクエストすることなく検証することが可能です。

制限事項

IAMポリシーシミュレーターではCondition句を含むSCPは評価されません。
ということは実装例2のようなタグベースの制御（aws:TagKeysなどの条件を使用）は、シミュレーターでは検証できないことになります。
このため条件付きSCPの動作確認は、実装例2で示したように実際のIAMコンソールでタグを操作して確認するなど、実環境での確認が必要です。

実装例1のようなCondition句の無いSCPであれば、IAMポリシーシミュレーターが有効です。

SCP設定における注意点

SCPは管理アカウントには適用されない

SCPはOrganizationsの管理アカウント自体には適用されません。管理アカウントにSCPをアタッチしても、そのポリシーは評価されず、管理アカウント内のユーザーやロールの操作は制限されません。SCPが実際に機能するのはメンバーアカウント（子アカウント）のみです。

そのため、管理アカウントで誤ってサービスを有効化してしまうリスクは残ります。管理アカウントは管理用途以外の通常運用では利用せず、IAMポリシーなどのアクセス権限は必要最低限にとどめる必要があります。

SCPはIAMよりも優先される

SCPは管理者権限を含む全てのIAMポリシーよりも優先して評価されます。AdministratorAccessポリシーを持つユーザーであっても、SCPで拒否されたアクションは実行できません。この明示的な拒否が最優先されるという特性により、組織レベルでの強力なガードレールとして機能します。

制限しているサービスを利用する必要がある場合

制限しているサービスを実際に使う必要が出てきた場合は、該当アカウントをSCP未適用の別OUに移動する、SCPポリシー自体を修正して特定条件下でのみ許可するなどの方法があります。本番環境専用のOUを作成し、そちらでは該当サービスを許可するという運用も有効です。

まとめ

本記事では、AWS OrganizationsのSCPを活用し、長期コミットメントが必要なサービスの意図しない利用を防ぐ方法を紹介しました。

これらのサービスは一度有効化してしまうと取り消しが困難なため、請求アラートなどの発見的統制では手遅れになります。SCPによる予防的統制を導入することで、検証環境での誤操作リスクを根本から防ぐことができます。

本記事で紹介した内容が、SCPポリシー設定の参考になれば幸いです。